Networked based computing systems and devices are configured to transmit and receive various types of data via network communication links. These communication links perform at various levels. In part, because of the varying performing network communication links, computing systems and devices, significant performance problems occur today when polling managed endpoints such as computing systems and devices. As the use of the network and cloud computing becomes more prevalent it is critical to minimize these significant performance problems.
Various types of service oriented architectures are used to manage information technology devices and services. A service-oriented architecture (SOA) is an architectural pattern in which application components provide services to other components via a communications protocol, typically over the network. The principles of service-orientation should be independent of any vendor, product or technology. An Application Programming Interface (API) can make several singular services accessible, such as, for example, retrieving an online bank statement. In this example, the service is one discretely invocable operation. As an example, in the Web Services Description Language (WSDL), the “service” is a complete interface definition that may list several discrete operations. And elsewhere, the term “service” is used for a component that is encapsulated behind an interface. A large software application may be composed by connecting client components to remote services, which in turn depend on other remote services and so on. An SOA assists in the connection of distributed software components, and to connect them in a loosely coupled way that makes it easier to replace one component with another. Web-based services, computing and data transfers are large consumers of available bandwidth and because of the expectancy of high performance by the users of web-based services, optimal performance management of an endpoint device, such as a computing client or server is important. Representational State Transfer (REST) is an example of an architectural technology protocol, and an approach to communications that is used in the development of Web services. Simple Object Access Protocol (SOAP) is another example of an architectural technology protocol for network based services. The use of REST is often preferred over Simple Object Access Protocol (SOAP) because REST does not consume as much bandwidth.
A REST client may issue a hypertext transfer protocol (HTTP) GET request to instruct the receiving server to transmit the current state of a resource (a managed endpoint in our case) back to the REST client. A representation of the resource state requested is typically returned using a standard media type like JavaScript Object Notation (JSON) or Extensible Markup Language (XML). As an example, if JSON or XML are used and the representation or data set is large, the request can take an unacceptable amount of time to complete. It is often the case that the client has previously requested the resource state of the same resource and that most of the resource state will have changed only incrementally since the last request for the resource state. Returning the entire resource state is therefore unnecessary and inefficient. However, the hypertext transfer protocol (HTTP) does not provide a way to get only the incremental state that has changed.
A partial solution to this problem exists today in the form of what is referred to as a “conditional GET” request. In this approach, the REST client issues a GET request with an If-Modified-Since header that specifies a timestamp. If the resource has changed since the specified timestamp, the server returns the new resource state. Otherwise, the server, returns a 304 (Not Modified) error indicating that the resource state is unchanged. This eliminates an unnecessary transfer of state in the case where the resource has not changed at all but, if the resource has changed even slightly, the entire resource state is returned.
A similar problem exists when the client updates the state of a resource using the PUT method. An HTTP extension called PATCH has been defined that allows the client to specify only the parts of the resource state that the REST client desires to update, avoiding the need to transfer the entire resource state. However, no equivalent has been defined for GET operations.
An approach in which the resource state of a managed endpoint is partitioned into several categories, depending on how often the piece of state in question is expected to change exists. Frequently changing pieces of a resource state are put in one category, less frequently changing pieces of a resource state are put in another category, and so on. A timestamp indicating when any data of the resource state in a given category last changed is returned in response to a poll. The client, in a second request, can then request a resource state update in only the categories which have actually changed since the client last requested the resource state update. This approach requires foreknowledge of what data or pieces of information are to be categorized as frequently updated and what data does not frequently change. In view of the foregoing, there is a need for improved systems and methods for enhancing the performance of resource state polling.